1. Technical Field
The present invention relates generally to software development tools and, more particularly, to a system and method for integrating entities using a graphical user interface (GUI) to provide user-interactive rule-based matching and difference reconciliation.
2. Description of Related Art
Typically, during software development, there are many situations where entities (e.g., objects, messages, or data) must be integrated, even though their detailed content is different (e.g. different data fields, types, aggregations, etc.). For example, during the development of object-oriented applications, common base classes may be factored out by analyzing the input classes to find xe2x80x9cmatchingxe2x80x9d data and methods which can be combined and then moved to the base class. Composite objects are formed by aggregating one or more input (component) classes that are exposed through a xe2x80x9ccombinedxe2x80x9d interface of the composite. Moreover, in messaging systems, multiple messages from different sources might have to be combined to form a single, integrated message.
Entities typically consist of many elements. When integrating entities, some elements of the entities to be integrated might match (i.e., they represent the same thing in the different representations) while others might not. The matching criteria used for integrating entities can vary greatly, ranging from simple element-name matching, to more complicated scenarios in which syntactically different input entities may actually represent the same thing. Once matching elements of the input entities have been identified, any differences between them must be reconciled, and then these reconciled elements are integrated to form the composite entity.
A similar, and even more common, situation for integrating entities is where entities must be shared by, or passed between, applications, but where the different applications have different expectations regarding the detailed content of such entities. This process is referred to by various names, depending on the nature of the entities involved. For example, if the entities are objects that communicate through interfaces, this process called xe2x80x9cinterface mappingxe2x80x9d or application program interface (API) mapping. If the entities are messages or data, the process is called xe2x80x9cmessage mappingxe2x80x9d and xe2x80x9cdata mapping,xe2x80x9d respectively. In these cases, integration is required not to produce a composite, but to map inputs to outputs. Indeed, the growing popularity of XML (Extensible Markup Language) as an interchange form has brought this issue to the forefront: XML dictates a common format, but not common content. Consequently, the integration of content elements is critical to realizing free interchange.
Conventionally, the process of integrating entities typically comprises two steps. The first step of the integration process typically involves examining the definitions of the entities to be integrated, and determining which of their elements match and how their differences can be reconciled. The second step of the integration process involves the execution of the integration in accordance with the determination made in the first step, which involves, for example, actually calling functions, or building integrated messages or data from actual input messages or data.
The first and second steps of the integration process typically occur at different times, referred to herein as xe2x80x9cdevelopment-timexe2x80x9d and xe2x80x9crun-time,xe2x80x9d respectively. xe2x80x9cDevelopment-timexe2x80x9d refers to the time when the first step of the integration process is performed. For example, in the case of message integration, the first step occurs when developers examine definitions of messages that must be integrated, while a system is being developed or modified. On the other hand, the second step of the integration process typically occurs during xe2x80x9crun-time,xe2x80x9d (e.g., in the case of message integration, the time when actual messages are being sent and received). It is to be understood, however, that there are cases where xe2x80x9cdevelopment-timexe2x80x9d and xe2x80x9crun-timexe2x80x9d occur simultaneously. For example, if integration were used in a programming environment to help factor out base classes, as described above, the resulting base classes will actually be produced right after the user specifies how to do so.
Conventionally, the xe2x80x9cdevelopment-timexe2x80x9d task of matching common definitions of elements, reconciling their differences and determining how to produce an integrated result is generally a manual operation with very little, if any, tool support. For example, some existing development-time matching software tools are limited in that they only display and help users visualize the input elements while the user matches and reconciles each input element, one by one (i.e., user tailoring), but do not support mechanisms for performing automatic matching of elements.
In addition, other conventional software tools (or builders) that are used for software development, in general (e.g., building UML (Unified Modeling Language) designs), provide a combination of automatic processing when possible, as well as user tailoring. These systems, however, may be configured such that all or some of the information resulting from user tailoring is lost when the tool is run again, which is known in the art as the xe2x80x9cround-tripxe2x80x9d problem. The diagram of FIG. 2A illustrates a general approach utilized by some conventional software builder tools. With a conventional software tool, the result (denoted by xe2x80x9cRxe2x80x9d), which is generated by processing input components 11 and 12, for example, is typically stored persistently, when the user is satisfied with the result. Although the result R is derived from processing the input components, it is nevertheless treated like an unrelated entity. Consequently, if the input components comprising the result R are slightly modified requiring some minor editing of the result R, the previous result must be analyzed in order to determine how the result R was derived from the inputs and what user tailoring was performed to obtain the result, which is difficult and sometimes virtually impossible. Alternatively, a new result can be produced by processing the modified inputs using the tool, discarding the previous result (including all the work the user put in to producing it), which is burdensome to the user.
Accordingly, there is a need for a software development system and method which supports both automatic and user guided rule-based matching and reconciliation for integrating one or more entities, whereby the matching/reconciliation rules are stored such that they can be recalled and applied during a subsequent editing session when the input entities change or a new composite entity of the inputs is desired.
The present invention is directed to a system and method for integrating entities using a graphical user interface (GUI) to provide user-interactive rule-based matching and difference reconciliation.
In one aspect of the present invention, a system for integrating entities employs a combination of default matching and reconciliation approaches and user tailoring to generate a composite entity from one or more input entities using a set of composition rules. The set of composition rules comprises a combination of default rules, as well as rules that represent user interactions that are performed via a graphical user interface when the user edits a composite result. The rules are captured and then stored persistently when the user requests that the composition be saved, such that the rules may be retrieved during a subsequent editing session associated with the same inputs. If the inputs change, the integration process (as specified by the rules) can automatically handle many changes. It is only when changed elements of the input are, or need to be, subject to specific rules that additional tailoring may be required.
In another aspect, the GUI is configured such that when a user selects a result element, the GUI will highlight the input elements that were integrated to form the selected result element. Similarly, when the user selects an input element, the GUI will highlight each result element it contributes to.
In another aspect, the user can select some specific inputs, and specify that they should match, or specify that matched elements should not be matched.
In another aspect, a dependency mechanism is employed to track which specific result elements are affected by a recorded rule in the rule set, as well as the manner in which the rule affects such result elements, such that the dependency information can be used to automatically disable earlier rules which conflict with subsequent rules, and allow the user to manually disable undesired rules. In particular, the dependency mechanism supports multi-level undo/redo and the direct manipulation of the rules (i.e. user actions). For example, an explicit rule that the user may have applied, such as deleting an element from the result, could be undone by simply removing the xe2x80x9cdelete rulexe2x80x9d from the rule set. This includes, for example, either performing an xe2x80x9cundoxe2x80x9d operation or selecting the specific xe2x80x9cdelete rulexe2x80x9d from the set and indicating that it should be removed.
These and other aspects, features and advantages of the present invention will be described and become apparent from the following detailed description of preferred embodiments, which is to be read in connection with the accompanying drawings.